RE: [-empyre-] archiving
Adam
The point you make about proprietory software and codecs is very
important and one we recognise. A year or so ago we did a major risk
audit of our digital collections precisely to identify these and other
risks. Certainly in respect of RealMedia files the proprietry nature of
the software and codec was one of the risk identified. So what can we
do? We we identified the possibility of converting the files to an
another format, seeking the "unstreamed" verions from the publisher and
monitoring the ongoing viability of the vender to assess the likelihood
of continued support. Now, identifying the issues and actually
implementing concrete measure to do something are different things.
There is considerable cost involved in undertaking measures to convert
of seek files from the publisher etc.
Our purpose in undertaking the risk assessment was really to clarify the
preservation metadata we need to maintain, so we know what files we have
(e.g. do they represent a significant holding in the archive) and what
is at risk; and to also be able to prioritise risks, so any measures we
take, given the inevitable resource constraints, are the most apposite
ones.
At least maintaining metadata about the archived resources and
undertaking analysis such as that which we have done helps us prepare
for the critical moments that are bound to occur. Whether we can ensure
that we do not lose access to anything is by no means certain. One would
have to expect that we will despite our best efforts.
Paul
-----Original Message-----
From: empyre-bounces@gamera.cofa.unsw.edu.au
[mailto:empyre-bounces@gamera.cofa.unsw.edu.au] On Behalf Of adam
Sent: Friday, 4 February 2005 12:51 PM
To: soft_skinned_space
Subject: RE: [-empyre-] archiving
Thanks Paul for a very interesting answer.
I am also interested in a topic related to what you write below:
>
> Take another couple or examples: RealMedia files are commonly
referenced
> with .ram metafiles which point to the actual media file, usually
> delivered from a RealMedia server. Automated harvesting will gather
the
> .ram file but it will not (currently at least) be able to gather the
.rm
> or .ra file from the RealMedia server and re-reference the .ram file
to
> point to an archived copy of the .ra or .rm file. In PANDORA we have
to
> contact the publisher to get them to supply the media files and we
> re-reference the .ram files to point to the archived version. This is
> archiving; and this sort of work has to be done at the time. Secondly,
> we have a number of subscription titles in PANDORA whereby we
negotiate
> with the publisher either to supply the files or provide us with
logins
> and passwords to harvest them. Here is an IA version for the
> subscription title the Justinian. Try and look at the articles.
> http://web.archive.org/web/20031205234822/http://www.justinian.com.au/
> Compare with a PANdORA version archived around the same time:
>
http://pandora.nla.gov.au/pan/10397/20031112/www.justinian.com.au/index.
> html
On an archiving level it looks like PANDORA is doing a very thorough
job.
However (this relates to archiving media in general) I was wondering if
there is any strategy by PANDORA for the long term preservation
of media files which have been created using proprietary codecs.
With realmedia files, for example, the content is archived with a codec
(the code that converts an audio or video file into a 'real media' file)
which is owned by Real Networks. The content itself may be owned by the
content producer, but the ability to decode the file for replay belongs
to someone else (RN).
If RN goes belly up it could be goodbye to codec distribution and hence
the content might not be easily replayed by anyone. Since RN doesnt like
anyone else to distribute their codecs then you could be stuck with
files
that are effectively dead to everyone except the 386 parked in the
PANDORA
backroom with the original codecs still installed ;)
This is a hypothetical scenario but one I find very possible if not
inevitable.
Does PANDORA have a strategy for this?
Kind regards
adam
_______________________________________________
empyre forum
empyre@lists.cofa.unsw.edu.au
http://www.subtle.net/empyre
This archive was generated by a fusion of
Pipermail 0.09 (Mailman edition) and
MHonArc 2.6.8.